[レポート] HSBCではどのようにサーバーレスを活用して何百万ものトランザクションをリアルタイムに処理しているか #reinvent

はじめに

福岡のyoshihitohです。re:Invent 2018のセッション「How HSBC Uses Serverless to Process Millions of Transactions in Real Time」についてレポートします。

セッション情報

セッション名

How HSBC Uses Serverless to Process Millions of Transactions in Real Time

スピーカー

• Santiago Freitas - Global Solutions Architect, AWS
• Srimanth Rudraraju - Lead Digital Solutions Architect, HSBC

概要

原文の引用です。

For large financial institutions, it can be extremely hard to predict when your architecture may need to scale to process millions of financial transactions per day. HSBC addressed this challenge by integrating its on-premises mainframe with AWS services such as AWS Lambda, Amazon Kinesis, and Amazon DynamoDB. This integration enables the bank to engage in real time with millions of retail banking customers in a more personal, dynamic, and useful way. The bank applies business logic to its transaction data, and it harnesses the information it gleans to communicate directly with customers through a messaging platform that runs on AWS. In this session, we share an architecture pattern that demonstrates how retail banks can add value by investing in their legacy system when integrating streaming data from on-premises systems to an event-driven, serverless architecture at scale.

以降がセッション内容です。

HSBCではどのようにサーバーレスを活用して何百万ものトランザクションをリアルタイムに処理しているか

アジェンダ

• HSBCの概要
• 顧客中心のコミュニケーション
• リアルタイムなサーバーレスイベント処理
• 設計の考慮点と学んだこと
• スケールを考慮した監視とアラート
• 主要な取り組み

世界をリードする国際銀行

ビジネスの多様性が技術を複雑にしている

• 複数の銀行プラットフォーム
• 地理的に分散した人々とシステム
• 厳しく規制された操作環境
• 急速に進化する顧客の要求・期待

HSBC Digital

• 単純化
• 革新
• より良い顧客体験

コミュニケーションをとる理由

• 我々が顧客の生活を単純化することで、人々は問題に注力できる

ソリューションの概要

Amazon Kinesis Data Stream(KDS)の主要コンセプト

• シャード
  • ストリームの基本スループットの単位
  • 到着時刻の順番で順序付けられたレコードを持つ
• データストリーム
  • シャードの論理的なグループ
• パーティションキー
  • Producerによって指定される識別子
  • データレコードをどのシャードに割り当てるかのルーティングで使う
• Producer
  • レコードをストリームに送る
  • レコードにパーティションキーを割り当てる
• データレコード
  • 下記の要素で構成される
    • シーケンス番号
    • パーティションキー
    • データ
• Consumer
  • ストリーム中のシャードからデータを取得する

AWS Lambda with KDS - スケールの振る舞い

• シャード数は並列数である
• 例えば、シャードが10個ある場合、10並列で実行する
• FIFO(先入れ先出し)の振る舞いはシャード単位
• シャードにレコードが無い場合、実行環境がコールドウェイトになるかもしれない

AWS LambdaとKinesis Data Stream

• Kinesis Data Streamをサブスクライブすると、自動的にレコードのバッチを読み込む。ラムダがストリームをポーリングする
• 例外が発生すると、シャードはブロックされるが他のシャードは例外を投げず、通常通りに処理する

再現性のあるユニークな相関IDが必要

• ソースから生成したIDを使って、システム全体を通してトランザクションを端から端まで追跡する

レコードを最大1回、少なくとも1回は処理する

ラムダとKinesi Data Streamについて学んだこと

• シャード数を増やしてもシステム全体のパフォーマンスが向上するとは限らない。バッチサイズの問題、パフォーマンスロードテスト
• 使用言語・VPC利用によるラムダの起動時間・実行時間の影響を考慮する
• Javaベースのファンクションは、Python/Nodeと比べて起動は遅いが、実行は早い
• VPCにアタッチしたラムダの場合、3GBのメモリが常に早いわけではない。多くの場合Javaベースの関数の場合1GBが最適だった。ENIの再利用を検討する
• レイテンシのSLA達成のため、pre-warmingなVPCアタッチファンクションを検討する

高度に制御してインターネットアクセスを提供する場合

• ラムダはVPCにアタッチすることができる
  • HSBCでは、すべてのラムダがVPC内にある
• インターネットアクセスは制限されたホワイトリストを利用したimmutable car proxyフリーとによって制御される
• 疑わしいファンクションがデプロイされた場合の影響範囲を制限する
• VPCピアリング依存を排除し、ルートテーブルの単純化しVPC間の独立性を向上させる

スケール可能にするため疎結合なネットワークアーキテクチャに

• VPCラムダをスケールさせるため、サブネットにはENIの数と同じだけ空きのIPアドレスが必要 (VPCに大きなCIDRブロックが必要)
• VPCエンドポイント経由でオンプレにアクセスする場合、VPCとDirectConnectにあるプロキシサーバーをカプセル化する

ネットワークで学んだこと

• ファンクションをまたぐチームでネットワークリソースがあると時間を節約できる
• スケールのため大きめのCIDRブロックを持つVPC内のラムダを使って、ラムダの独立性を検討する (IPアドレスの不足を回避)
• VPCラムダはセキュリティグループとVPCフローログに対応していて、セキュリティチームがこれらの機能を必要とするかもしれない
• ラムダ起動APIはVPCエンドポイントとして利用できない。それ以前にVPC外で起動したファンクションの失敗要因になる。代わりにAPIゲートウェイかKinesi Data Streamを使う

監視とアラート

• 主要なメトリクス
  • スループット
  • レイテンシ
  • エラー
  • システムの状態
• 主要な挑戦
  • サーバーレスコンポーネントをまたいだレイテンシ計測
  • AWS Tagging Strategyを活用したDataDogのメトリクス

ダッシュボード

• パイプラインでアプリケーションコードと一緒にデプロイする
• アプリケーションとインフラサービスで論理的にグループ化
• Anomaly Detectionを活用してスマートに検知・解釈する

主要な取り組み

• 「一度データを抽出して何度も再利用する」の原則に従うことで新しい顧客体験への力にする
• ソースから再現性のある相関IDを生成することは分散システムにとってとても重要
• ロードテストによってより良いチューニングを施し、問題点を明確にする
• AWSサービスのソフトリミット/ハードリミットを知る
• サービスの独立性と本番環境のスケールに基づいてネットワークアーキテクチャを計画する
• ログや監視、アラートなどの既存の操作とクラウドの操作をどうやって統合するか検討する

おわりに

サーバーレスの実際の活用事例が聞けてとても勉強になりました！向いていること、向かないことの特性を理解して適切なアーキテクチャを組んでいきたいですね。